Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Vector Object server #3930

Closed

Conversation

AlexeyMerzlyakov
Copy link
Collaborator

@AlexeyMerzlyakov AlexeyMerzlyakov commented Nov 2, 2023

Adding Vector Objects support to costmaps (and OccupancyGrid maps).

This is done by new Vector Object server, working as a separate node. In this server, Vector Objects are being putted into OccupancyGrid map. OccupancyMap is being published via output map topic (the performance question of map publishing was discussed in the original ticket). VO-server have an ability to support moving objects working dynamically with a given rate. If at least one vector object is being published in separate than "map" frame, resulting OccupancyGrid is being updated dynamically with this rate.

Support of vector objects in costmaps could be enabled by switching published by VO-server map as an input mask for Keepout Costmap Filter (it can't be done via Static Layer as it reads input map once and thus can not support moving objects; transfers input OccupancyGrid map to costmap w/o objects overlay on initial background; works with fixed-size input maps while VO-server can change its origin and dimensions).
Also, they are being able to work with other Costmap Filters (Speed Filter), to have a support for speed restricting areas specified by polygons).


Basic Info

Info Please fill out this column
Ticket(s) this addresses #3017
Primary OS tested on Ubuntu 22.04
Robotic platform tested on TB3 simulation in Gazebo

Description of contribution in a few bullet points

  • Added new Vector Object server into nav2_map_server
  • Supported polygons and circles vector objects for now
  • New messages: PolygonVO.msg and CircleVO.msg for them
  • New services to work with Vector Objects: AddShapes.srv, GetShapes.srv and RemoveShapes.srv
  • raytraceLine(), bresenham2D() algorithms were moved into common nav2_utils part
  • Such functions as maskToWorld()/worldToMask(), getMaskData() were moved to nav2_util/occ_grid_utils.hpp common module working OccupancyGrid-s

Use-cases to be covered by this feature (from the #3017 discussions):

  • Testing/virtual objects
  • No-access-zone
  • Speed restriction areas
  • Robot footprint (or any other moving objects) replacement
  • Areas restriction for UAVs to define a flying zone (outer / boundary) with obstacles (inner rings / holes)
  • Remove some area from costmap (need KeepoutFilter modification: new "always overlay" overlay parameter)

Description of documentation updates required from your changes

  • Chapter in Iron to Jazzy migration guide
  • Parameters page on Configuration guide
  • Demo tutorial of using the VO-server in costmaps

Future work that may be required in bullet points

  • Consider to move point-in-polygon implementation (which is currently written twice in the code: initially for Collision Monitor, and for VO-server) to common nav2_utils function
  • Consider to move Bresenham3D algorithm into common nav2_utils part as well as it was made for Bresenham2D one
  • Testcase coverage once design will be agreed

For Maintainers:

  • Check that any new parameters added are updated in navigation.ros.org
  • Check that any significant change is added to the migration guide
  • Check that any new features OR changes to existing behaviors are reflected in the tuning guide
  • Check that any new functions have Doxygen added
  • Check that any new features have test coverage
  • Check that any new plugins is added to the plugins page
  • If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

Copy link
Member

@SteveMacenski SteveMacenski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is alot of code to review, I really didn't have a chance yet to go through the cpp files in much detail, but I didn't want to delay the few comments I have now another few days while I continue to review the rest (its a big PR).

Higher level comment that this will really need alot of documentation on Navigation.ros.org to support (e.g. how to use tutorial / demo) and its missing test coverage

nav2_map_server/CMakeLists.txt Show resolved Hide resolved
nav2_map_server/CMakeLists.txt Outdated Show resolved Hide resolved
nav2_msgs/msg/PolygonVO.msg Outdated Show resolved Hide resolved
nav2_msgs/msg/CircleVO.msg Outdated Show resolved Hide resolved
nav2_msgs/srv/RemoveShapes.srv Show resolved Hide resolved
nav2_map_server/src/vo_server/vector_object_server.cpp Outdated Show resolved Hide resolved
nav2_map_server/src/vo_server/vector_object_server.cpp Outdated Show resolved Hide resolved
@AlexeyMerzlyakov
Copy link
Collaborator Author

AlexeyMerzlyakov commented Nov 7, 2023

@SteveMacenski, thank you for having the time to promptly review the PR, which became to be really large change. I'll prepare the fixes to meet the review comments soon. Only one thing: moving from OccGrid maps -> to Costmap2D is still doubtful for me, so I've left the responds for a few review items from above.

Copy link
Member

@SteveMacenski SteveMacenski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs tests / docs 😄

nav2_map_server/src/vo_server/vector_object_server.cpp Outdated Show resolved Hide resolved
nav2_map_server/src/vo_server/vector_object_server.cpp Outdated Show resolved Hide resolved
value: 10
center: [3.0, 3.0]
radius: 0.5
uuid: "7b3f3d7d-135c-4b6c-aca1-7a84d1050505"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't think about this before, but if we're asking users to specify shapes in a params file, UUID might not be the best option. That would require them to offline generate some UUIDs to put into the params file. If we instead just made it an id field of unsigned int then it would be easier to enumerate them in a config file.

When its generated via code, UUID makes sense, but not when manually requiring annotation

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, uuid ROS-param is optional, it could be skipped by developer: in this case it will be generated to a new shape automatically. In this case, does it still have a sense to have an ID?

I'm asking, because when we have an ID, we do not need to support UUID anymore: any shape could be uniquely addressed by its ID, it also could be easily generated if not specified w/o any UUID dependency. So we could just skip it.

What do you think, maybe it is better to totally refuse from UUID usage in favor of ID?
Another question that logically raises here: how about to use ID of string type, which could be called "name"? It is even much more user-friendly, than unsigned ints, I believe; and we do not need to worry about ID-s/UUID-s in ROS-parameters: name of each shape is already specified in its parameters path and shapes array.

Copy link
Collaborator Author

@AlexeyMerzlyakov AlexeyMerzlyakov Nov 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, from my point of view, using UUID is still the nice way for UX:

  • We could optionally specify it in ROS-parameters
  • We could optionally specify it in AddShapes.srv service request when adding a new shape
  • And we to specify it on mandatory basis when modifying existing shape while calling AddShapes.srv and removing some specific shape in RemoveShapes.srv

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uuid ROS-param is optional, it could be skipped by developer

Ah, ok! I'd just make sure to document that in the param guide that its optional except if you might want to remove it, in which case specifying it is important.

@AlexeyMerzlyakov
Copy link
Collaborator Author

AlexeyMerzlyakov commented Nov 16, 2023

Regarding #3930 (comment), I've missed it initially, but currently during the testcase development it was discovered that switching to std::unordered_mapbroke the OVERALY_SEQ updating mechanism, where the shapes are put on map in the same order, as they arrived (independently on their values). This sequential updating mechanism is important to support some use-cases, such as outer ring with inner objects inside this ring, which was reported in the initial ticket.

To do this, there is a way to add unsigned int seq field to the Polygon and Circle classes, but I think it will overcomplicate the overall structure.
So, unfortunately, better way - is roll-back the usage of std::unordered_map in favor of std::vector-s where we could save the order of shapes arrived.

@SteveMacenski
Copy link
Member

SteveMacenski commented Nov 18, 2023

where the shapes are put on map in the same order, as they arrived (independently on their values).

Ohhhhhhhhhh yeah, that sounds like a problem :( Sorry about that bad suggestion making extra work!

@AlexeyMerzlyakov
Copy link
Collaborator Author

AlexeyMerzlyakov commented Nov 20, 2023

Not a problem at all. This is some kind of working process while making better contribution. Restored back vectors usage in 0ddb73c.

There are also tests covering new functionality were added in 355b95b. What is need ToGo - it is documentation (MG, Configuration pages, tutorial).

@AlexeyMerzlyakov
Copy link
Collaborator Author

Everything is set to be completed for today:

Copy link
Contributor

mergify bot commented Dec 23, 2023

This pull request is in conflict. Could you fix it @AlexeyMerzlyakov?

@AlexeyMerzlyakov
Copy link
Collaborator Author

Force-pushed the branch resolving conflicts with latest main. @SteveMacenski, do we plan to merge this PR or this feature is no more necessary?

@PranavShevkar
Copy link

Tested on Rolling. Looks good and works fine

Copy link
Contributor

mergify bot commented Feb 13, 2024

This pull request is in conflict. Could you fix it @AlexeyMerzlyakov?

AlexeyMerzlyakov and others added 12 commits February 22, 2024 13:01
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Co-authored-by: Steve Macenski <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
Signed-off-by: Alexey Merzlyakov <[email protected]>
* Corrected headers
* Functions ordering
* Comment fixes

Signed-off-by: Alexey Merzlyakov <[email protected]>
* Correct licensing years
* Fix Vector Object server dependencies
* Funcion rename for better readability
* Improve/fix comments

Signed-off-by: Alexey Merzlyakov <[email protected]>
@AlexeyMerzlyakov
Copy link
Collaborator Author

AlexeyMerzlyakov commented Feb 22, 2024

Resolved small merge conflict and force-pushed development branch.
@SteveMacenski, are we ready to merge this change? (from my side, everything: change, tests, docs - are ready)

Copy link
Contributor

mergify bot commented Apr 23, 2024

This pull request is in conflict. Could you fix it @AlexeyMerzlyakov?

@ajtudela
Copy link
Contributor

ajtudela commented May 12, 2024

Bumping this!

This server would be very beneficial for one our current use cases. Let me know if I can help to wrap this up.

@SteveMacenski
Copy link
Member

This is functionally on permanent hold as Alexey is no longer working on this project in a professional capacity. If someone wants to pick this up, test it, and resubmit a new PR with fixes made, we're happy to review!

@ajtudela
Copy link
Contributor

@SteveMacenski I want to finish this PR if Alexey can't because we use it in our system. Do I make a new PR with this exact commits and we go from there?

@SteveMacenski
Copy link
Member

Sure, I'd make sure to go through the ticket and the review comments here to understand the remaining efforts required

@ajtudela ajtudela mentioned this pull request Sep 17, 2024
7 tasks
@SteveMacenski
Copy link
Member

#4680 to supersede

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants